[Dev] Enhancing development workflow
eduard.bartosh at intel.com
Wed Oct 29 13:52:45 GMT 2014
> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Wednesday, October 29, 2014 2:46 PM
> To: Bartosh, Eduard
> Cc: Stephane Desneux; Lehtonen, Markus; dev at lists.tizen.org
> Subject: Re: [Dev] Enhancing development workflow
> On Wed, 2014-10-29 at 11:39 +0000, Bartosh, Eduard wrote:
> > Hi,
> > -----Original Message-----
> > From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> > Sent: Wednesday, October 29, 2014 11:20 AM
> > To: Bartosh, Eduard
> > Cc: Stephane Desneux; Lehtonen, Markus; dev at lists.tizen.org
> > Subject: Re: [Dev] Enhancing development workflow
> > On Tue, 2014-10-28 at 17:05 +0000, Bartosh, Eduard wrote:
> > > > So you're describing another type of submissions, which should be
> > > handled by the users themselves: it'd be the same mechanisme as
> > > sandboxes in gerrit, but for builds. And when you're here, you're
> > > not far from using home projects in OBS, which is not what we want.
> > >
> > > Yeah, it would be good to isolate this types of submissions in
> > > another namespace (home:devel: or something like that). However, I
> > > don't agree that prerelease projects can't be used for this purpose right
> > > The only thing which needs to be done is to agree with RE that they
> > > don't touch submission until devs say it's ok to integrate it. Not a
> > > big deal from my point of view.
> > > I disagree about this being not a big deal. This relies on
> > out-of-band, unrecorded communication between people, which is
> > error-prone. What if one RE knows not to accept, but some other RE
> > doesn't and accidentally accepts?
> > What if developer will ask both REs?
> This helps of course, but doesn't address the underlying problem. It's easy
> for you and me, but most developers don't even know who's currently the
> active RE(s).
We can setup tizen-<profile>-re@ aliases to address that I guess. Or just put names of current RE on the wiki.
> > Let me make it clear - I'm not saying this is a perfect scheme. I'm
> > saying that this is working scheme and can be used right away. I'm as
> > RE don't see this as a big deal. If developer asks me not to touch
> > something until it's ready - I'm ok with this. To make this kind of
> > projects easily recognizable we can use predefined submit tags for
> > them. The benefits of this approach is: RE will see those projects can
> > ping developers if they forget about them. Developers can get package
> > repositories, images and even test results for their submissions. All
> > of it is available for usage right now!
> Using special tags would be better. Is it already possible? I think I ran into
> some kind of name format check when I tried to use a normal string as tag
I meant using gbs stump --tag with special timestamp like 20014MMDD.00XX00 or similar (XX - unique developer id, assigned by RE).
So the procedure would be the following:
- developer submits packages to the project using --tag 20014MMDD.00XXXX
- developer sends e-mail to RE asking not to touch it until further notification (later on it can be possible to do in panel.tizen.org)
- developer re-tags changes with this tag and resubmits them again and again until project is ready for integration. All prerelease artifacts (package repos, images, manifest, etc) are available for developer on download server.
- developer uses https://panel.tizen.org/app/submissions/mine/ to see all info about submission
- developer notifies RE when submission is ready to be integrated (later on it can be possible to do in panel.tizen.org)
- RE accepts submission
> > > Tagging different "gbs submit"s with the same tag has a similar problem:
> > > while the developer is in the process of adding submits, the group
> > submission is incomplete and must not be accepted. If for some reason
> > the developer gets interrupted, the group submission is left in an
> > incomplete state and might get accepted accidentally (assuming that it
> > compiles).
> > Unless developer contacts RE and asks not to accept this particular
> > submission. Simple like that.
> Same problem (dependency on out-of-band communication). It works, but I
> wouldn't call that a robust process.
It's better than nothing and good enough to start with. Of course we can continue discussing perfect solution instead of starting to use what we already have.
> Best Regards, Patrick Ohly
> The content of this message is my personal opinion only and although I am an
> employee of Intel, the statements I make here in no way represent Intel's
> position on the issue, nor am I authorized to speak on behalf of Intel on this
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
More information about the Dev