On Tue, May 23, 2017 at 12:21:35PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"):
> > A way to set the version during the build, as you suggest, would be
> > sufficient to cover this. It is hard to see how we could relieve the
> > user of the need to understand how to choose a version number for a .deb
> > for testing. An option to set the version in the build command line
> > would remove the need for Debian source package knowledge.
>
> It would be best if the user would just pass an option to say `pls
> pick version number' and some tool would make a reasonable stab at it.
Ah, I see, that would indeed be nice.
> > > * Pull request workflow for submitting changes. This should
> > > eventually turn into a bug submission to the Debian BTS. This
> > > sounds to me like it probabl needs to be a web service, but
> > > perhaps some local client utility that looked enough like a web
> > > page would do.
> >
> > We basically already have all the pieces:
> >
> > - git-request-pull(1)
> > - reportbug(1)
> > - git hosting on alioth / our shiny pagure git hosting (coming soon)
> >
> > dgit could ship a script that ties these together. (The reason I suggest
> > using our own git hosting is so that the branch doesn't disappear -- one
> > advantage of patches in the BTS is that they can't 404.)
>
> I'm not sure that a command-line tool is what our target audience for
> this would be looking for. But contributions certainly welcome.
Hmm, I hadn't thought that it was the text-only nature of the interface
that is proving off-putting. I thought it was purely the workflow.
What I described could be wrapped up in a webapp or a desktop GUI --
reportbug already has one.
I think we would need to see how pagure pans out before writing any code
for this, as it might work as some sort of plug-in.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature