Re: [fossil-users] Ticket system -- blockers
On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice jayare...@gmail.comwrote: During the push, it is noticed that R(N) says bug B2 is closed while R' says it is open and blocked by B1 (and that A specified the block), which is open both in R' and R(N). N should be notified of this as it is something which cannot be automatically resolved by fossil, and given an opportunity to specify what to do. This would be a fundamental change to the design and philosophy of Fossil. You are asking that push operations become atomic (either all artifacts are pushed or else none are) and that the push can only succeed if certain constraints are satisfied. As currently designed, Fossil does push operations incrementally. And a push never fails due to constraints. The current model is that a repository is an unordered bag of blobs (called artifacts). A push from A to B merely causes all artifacts held by A to be copied into B if they are not already there. The push logic does not know or care about the content of the individual artifacts. There are no constraints that prevent certain artifacts from being pushed from A to B based on content. If A has push permission, then A can push any artifact it wants, whenever it wants, and it can push multiple artifacts in any order that it wants. The push and pull logic never examines the content of an artifact. Push and pull are just transport. Like TCP/IP, that merely moves information from one place to another without regard to the meaning of that information, push and pull just move artifacts from one repository to another with the objective that both repositories end up holding all artifacts. Now, you could in theory change the philosophy of Fossil so that push and pull did examine the content of artifacts as they moved over the wire, and rejected artifacts that violated constraints. But to do so would seriously complicate matters, both for the implementation and for the user. Suppose you had a case where repositories A and B held incompatible artifacts, artifacts that caused constraint violations. A could not push to B without violating a constraint so the push would fail. But if pushing from A to B violated a constraint, so would pulling from B back to A. The user of A is therefore stuck. He cannot pull without resolving the constraint. He cannot resolve the constraint without knowing what the constraint is. And he cannot find out what the constraint is without doing a pull. Stalemate. So maybe you add some logic to deal with this first-level constraint violation and prevent stalemate. I think you would quickly run into lower-level and more subtle kinds of stalemates, though. I fear that such a design would quickly devolve into playing whack-a-mole with constraints. How is this different from synching other things, such as code etc, where multiple people might make incompatible changes to the same object which require human intervention to resolve? Push and pull never create conflicts. Conflicts only occur during a merge operation, which is something that only occurs in a local checkout. A push or a pull might create a new branch or fork in the code, but it never creates a conflict. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
Applying constraints as receiver end filtering could be very useful and I think it could fit the sync model if not needed blobs were not necessarily dropped but a record was kept so that they wouldn't be sync'd and they are kept out of the list of blobs. Essentially something similar to what the shun mechanism does now. I think features like the ticket blocking and pulling only a specific branch could be implemented on top of such a mechanism with the caveat that all data was being sync'd at least once. I.e. this would add control and management power to fossil but it would not be a bandwidth saving mechanism. Consider an autoshun mechanism that for example suppresses blobs based on branch name. To make it work this blob suppression mechanism would not remove blobs on rebuild. Could this work? On Mon, Oct 7, 2013 at 12:43 AM, Richard Hipp d...@sqlite.org wrote: On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice jayare...@gmail.comwrote: During the push, it is noticed that R(N) says bug B2 is closed while R' says it is open and blocked by B1 (and that A specified the block), which is open both in R' and R(N). N should be notified of this as it is something which cannot be automatically resolved by fossil, and given an opportunity to specify what to do. This would be a fundamental change to the design and philosophy of Fossil. You are asking that push operations become atomic (either all artifacts are pushed or else none are) and that the push can only succeed if certain constraints are satisfied. As currently designed, Fossil does push operations incrementally. And a push never fails due to constraints. The current model is that a repository is an unordered bag of blobs (called artifacts). A push from A to B merely causes all artifacts held by A to be copied into B if they are not already there. The push logic does not know or care about the content of the individual artifacts. There are no constraints that prevent certain artifacts from being pushed from A to B based on content. If A has push permission, then A can push any artifact it wants, whenever it wants, and it can push multiple artifacts in any order that it wants. The push and pull logic never examines the content of an artifact. Push and pull are just transport. Like TCP/IP, that merely moves information from one place to another without regard to the meaning of that information, push and pull just move artifacts from one repository to another with the objective that both repositories end up holding all artifacts. Now, you could in theory change the philosophy of Fossil so that push and pull did examine the content of artifacts as they moved over the wire, and rejected artifacts that violated constraints. But to do so would seriously complicate matters, both for the implementation and for the user. Suppose you had a case where repositories A and B held incompatible artifacts, artifacts that caused constraint violations. A could not push to B without violating a constraint so the push would fail. But if pushing from A to B violated a constraint, so would pulling from B back to A. The user of A is therefore stuck. He cannot pull without resolving the constraint. He cannot resolve the constraint without knowing what the constraint is. And he cannot find out what the constraint is without doing a pull. Stalemate. So maybe you add some logic to deal with this first-level constraint violation and prevent stalemate. I think you would quickly run into lower-level and more subtle kinds of stalemates, though. I fear that such a design would quickly devolve into playing whack-a-mole with constraints. How is this different from synching other things, such as code etc, where multiple people might make incompatible changes to the same object which require human intervention to resolve? Push and pull never create conflicts. Conflicts only occur during a merge operation, which is something that only occurs in a local checkout. A push or a pull might create a new branch or fork in the code, but it never creates a conflict. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Mon, Oct 7, 2013 at 11:31 AM, Matt Welland estifo...@gmail.com wrote: Applying constraints as receiver end filtering could be very useful and I think it could fit the sync model if not needed blobs were not necessarily dropped but a record was kept so that they wouldn't be sync'd and they are kept out of the list of blobs. Essentially something similar to what the shun mechanism does now. In theory, such ticket filtering could be done, but I don't know if there is an easy to find the artifacts making up a specific ticket. From what I have read, the ticket table holds the most recent field values and their respective timestamps so processing artifacts is only done when new ones arrive or a rebuild is done. Unless the ticket table also has a field for a list of the artifacts for each ticket, finding the artifacts required to detect restricted sequences of field value changes would be a very intensive operation. But, even if such checking could be added, there could still be pending ticket changes from an offline contributor. So far, the distributed ticketing system I know of is Fossil. It's distributed nature is going to introduce problems you won't see in a system that requires a connection to a central repository for operation. In an office situation where your team always has access to the main repository and you have auto-sync enabled, then Fossil will effectively work like a non-distributed system. But the main advantage of a distributed system like Fossil is to enable (mostly) normal operation in situations where one or more team members needs to get work done without constant access to the main repository. This could arise from having a geographically dispersed team or from the need to send someone to, for example, an outside testing facility. Where I work, our process is that we don't close or resolve tickets until the actions to date have been reviewed - and their affect on related tickets. That way, everyone knows before the ticket gets resolved or closed. (In theory, push/pull could be done via email. For small changes, this could be practical. Once libfossil is far enough along, maybe I will look into implementing an app to do that, at least for ticket updates. But even then, there will be significant lag in updates.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ticket system -- blockers
Hi all,
About 4 years ago I wrote about a missing feature -- a way to specify that
a ticket is a blocker of another ticket. There was a useful suggestion from
Brian T... time passed and recently this feature has become more and more
urgent to me, so I decided to implement it.
For those interested I report changes to the ticket table (below) and view
and edit pages (attached source). A remaining issue is that as there're no
hard db constraints on blockers there seems to be no way to verify that the
blocker to be added is actually a valid ticket uuid. Basically, user can
add any text as a blocker.
Any comments appreciated.
Best regards,
Jacek
Changes against Fossil version [d2e07756d9] 2013-02-16 00:04:35
In the ticket table (Admin/Tickets/Table) add an extra column:
CREATE TABLE ticket(
...
comment TEXT,
blockers TEXT
);
...
th1
if {![info exists mutype]} {set mutype {[links only]}}
if {![info exists icomment]} {set icomment {}}
if {![info exists username]} {set username $login}
if {[info exists submit]} {
if {$mutype eq Wiki} {
set mimetype text/x-fossil-wiki
} elseif {$mutype eq HTML} {
set mimetype text/html
} elseif {$mutype eq {[links only]}} {
set mimetype text/x-fossil-plain
} else {
set mimetype text/plain
}
# Set blockers according to the buffered new_blockers list
set blockers $new_blockers
submit_ticket
set preview 1
}
/th1
table cellpadding=5
trtd class=tktDspLabelTitle:/tdtd
input type=text name=title value=$title size=60 /
/td/tr
trtd class=tktDspLabelStatus:/tdtd
th1combobox status $status_choices 1/th1
/td/tr
trtd class=tktDspLabelType:/tdtd
th1combobox type $type_choices 1/th1
/td/tr
trtd class=tktDspLabelSeverity:/tdtd
th1combobox severity $severity_choices 1/th1
/td/tr
trtd class=tktDspLabelPriority:/tdtd
th1combobox priority $priority_choices 1/th1
/td/tr
trtd class=tktDspLabelResolution:/tdtd
th1combobox resolution $resolution_choices 1/th1
/td/tr
trtd class=tktDspLabelSubsystem:/tdtd
th1combobox subsystem $subsystem_choices 1/th1
/td/tr
th1enable_output [hascap e]/th1
trtd class=tktDspLabelContact:/tdtd
input type=text name=private_contact size=40
value=$private_contact /
/td/tr
th1enable_output 1/th1
trtd class=tktDspLabelVersionnbsp;Foundnbsp;In:/tdtd
input type=text name=foundin size=50 value=$foundin /
/td/tr
tr
td class='tktDspLabel'Blockers:/td
th1
if {! [info exists new_blockers]} {
set new_blockers $blockers
}
if {[info exists addblckrbtn]} {
if {[info exists new_blocker]} {
# Check whether the added blocker is already in the list
set add_new_blocker 1
for {set b 0} {$b [llength $new_blockers]} {set b [expr {$b + 1}]} {
set to_check [lindex $new_blockers $b]
if {![string compare $new_blocker $to_check]} {
set add_new_blocker 0
break
}
}
if {$add_new_blocker} {
set new_blockers $new_blockers $new_blocker
}
}
} elseif {[info exists delblckrbtn]} {
if {[info exists blocker_list]} {
# Generate a list of blockers that is clear from the deleted blocker
set cleared_blockers
for {set b 0} {$b [llength $new_blockers]} {set b [expr {$b + 1}]} {
set to_check [lindex $new_blockers $b]
if {[string compare $blocker_list $to_check]} {
set cleared_blockers $cleared_blockers $to_check
}
}
set new_blockers $cleared_blockers
}
}
html input type='hidden' name='new_blockers' value='$new_blockers' /
/th1
tdth1combobox blocker_list $new_blockers 3/th1
input type=submit name=delblckrbtn value=Del blocker //td
/tr
tr
td/td
tdinput type=text name=new_blocker size=20 /
input type=submit name=addblckrbtn value=Add blocker //td
/tr
trtd colspan=2
Append Remark with format
th1combobox mutype {Wiki HTML {Plain Text} {[links only]}} 1/th1
from
input type=text name=username value=$username size=30 /:br /
textarea name=icomment cols=80 rows=15
wrap=virtual class=wikiedit$icomment/textarea
/td/tr
th1enable_output [info exists preview]/th1
trtd colspan=2
Description Preview:brhr
th1
if {$mutype eq Wiki} {
wiki $icomment
} elseif {$mutype eq Plain Text} {
set r [randhex]
wiki verbatim-$r\n[string trimright $icomment]\n/verbatim-$r
} elseif {$mutype eq {[links only]}} {
set r [randhex]
wiki verbatim-$r links\n[string trimright $icomment]/verbatim-$r
} else {
wiki nowiki\n[string trimright $icomment]\n/nowiki
}
/th1
hr
/td/tr
th1enable_output 1/th1
tr
td align=right
input type=submit name=preview value=Preview /
/td
td align=leftSee how the description will appear after formatting./td
/tr
th1enable_output [info exists preview]/th1
tr
td align=right
input type=submit name=submit value=Submit /
/td
td align=leftApply the changes shown above/td
/tr
th1enable_output 1/th1
tr
td align=right
input type=submit name=cancel value=Cancel /
/td
tdAbandon this edit/td
/tr
/table
table
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 3:51 PM, Jacek Cała jacek.c...@gmail.com wrote: ...For those interested I report changes to the ticket table (below) and view and edit pages (attached source). A remaining issue is that as there're no hard db constraints on blockers there seems to be no way to verify that the blocker to be added is actually a valid ticket uuid. Basically, user can add any text as a blocker. Any real blocking support has to be integrated with the system as a whole, from the human processes to the software (but primarily the human processes). What does a block actually block? Does it block a release (fossil doesn't know what a release is), does it cause work to be reprioritized (also something fossil knows nothing about), or does it have some other effect? My point being only that i don't think there's anything Fossil can reasonably know/do in regards to a blocker except for what you've already done: CREATE TABLE ticket( ... comment TEXT, blockers TEXT ); IMO that doesn't really belong in the default ticket schema system because... (and i know this is going to sound somewhat lame!)... it's never been a pressing issue before (in 6 years of use). It may have been brought up a time or two (i don't recall, but i also don't immediately recall whether or not i've already eaten today :/). If it's added, i'm pretty sure it will be ignored by 99% of users, in which case leaving it as an optional client-side customization seem more practical to me. But of course that's just my personal opinion and not some sort of official statement :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
in the field (possibly without commas, or a mixture). Ignoring the complication of having to parse/grok the content (it's a minor complication, granted, but parsing text is always at least a slight annoyance), there's another problem: DVCS. i edit the field, then you close the ticket in your copy before i sync my changes to the blocker list. So we've now got a closed ticket with open blockers. i don't see how that could be made to work (meaning automatically enforced) 100% reliably in a DVCS. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist. Cheers, Jacek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
Jacek, I just started using fossil. It is heartening to see there are so many people contributing. I haven't run into that need yet, but it doesn't mean i won't. Thanks for putting this out there. I will know where to find it if that need arises. Krister On Wed, Oct 2, 2013 at 9:31 AM, Jacek Cała jacek.c...@gmail.com wrote: in the field (possibly without commas, or a mixture). Ignoring the complication of having to parse/grok the content (it's a minor complication, granted, but parsing text is always at least a slight annoyance), there's another problem: DVCS. i edit the field, then you close the ticket in your copy before i sync my changes to the blocker list. So we've now got a closed ticket with open blockers. i don't see how that could be made to work (meaning automatically enforced) 100% reliably in a DVCS. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist. Cheers, Jacek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 10:31 AM, Jacek Cała jacek.c...@gmail.com wrote: in the field (possibly without commas, or a mixture). Ignoring the complication of having to parse/grok the content (it's a minor complication, granted, but parsing text is always at least a slight annoyance), there's another problem: DVCS. i edit the field, then you close the ticket in your copy before i sync my changes to the blocker list. So we've now got a closed ticket with open blockers. i don't see how that could be made to work (meaning automatically enforced) 100% reliably in a DVCS. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist Having a list of any related tickets is useful. Your implementation is impressive and good. My own was just an extra field with a text area in the ticket edit page - though I did actually render links on the ticket view page. I might use a simplified version of yours. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 10:47 AM, Stephan Beal sgb...@googlemail.com wrote: Most just don't generate as much noise as i do, so you haven't seen them yet in your short time here ;). Noise? I'd say you have a very high signal-to-noise ratio. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ticket system
Dear developers, First thank you for nice piece of software. I am using fossil for some of my projects and some users wants more featured ticket system. For example spent time for solving the issue. What is your opinion on that. I am trying avoid installing another software. TIA -- Regards Jan Jurák ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system
On Thu, Aug 29, 2013 at 6:02 PM, Jan Jurak yan.ju...@gmail.com wrote: Dear developers, First thank you for nice piece of software. I am using fossil for some of my projects and some users wants more featured ticket system. For example spent time for solving the issue. What is your opinion on that. I am trying avoid installing another software. You can easily extend the info tracked by fossil to include that: http://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ticket system bug, additional columns
Hello All, There seems to be a bug in the ticket system. Could someone verify this. I added an assigned_to column into the fossil ticket system. When I edit a ticket's assigned_to column and comment, an artifact is generated (viewable in the admin/log page) but it does not seem to get applied to the ticket. With some experimentation I've noticed that the name of the column that you add and try to modify along with the comment field seems to be the culprit. For example if you create an assigned_to column, and try to edit it as well as the comment you generate an artifact like this (note that the J fieldnames seem to be alphabetized). It does not work: D 2010-11-15T23:38:35 J assigned_to eriklechak J +comment \n\nhr\s/ieriklechak\sadded\son\s2010-11-15\s23:38:35:/ibr\s/\nabcd K b8d3a9acb552bc11cc01483fcc710d6c994198e3 U eriklechak Z 9e9120a9d85b67a50280a96b04d117c6 However, if instead of creating an assigned_to column you create and xassigned_to column, and repeat the process of setting it and the comment you get this working artifact (note that the xassigned_to field comes after the J +comment field): D 2010-11-15T23:44:29 J +comment \n\nhr\s/ieriklechak\sadded\son\s2010-11-15\s23:44:29:/ibr\s/\ntyui J xassigned_to eriklechak K b8d3a9acb552bc11cc01483fcc710d6c994198e3 U eriklechak Z a5f5eb871eb8334469c721c11c000a11 With the assigned_to column, if the only thing you change is the assigned_to field it works as well: D 2010-11-15T23:39:32 J assigned_to eriklechak K b8d3a9acb552bc11cc01483fcc710d6c994198e3 U eriklechak Z 739866d3b7281ea4f0019f9352d22de1 This makes me think that any field added that alphabetically comes before comment or possibly any J +fieldname section can not be in the same artifact. --Erik Lechak ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ticket system - blockers
Hi all, I wonder if there is any simple way to add `blocker' feature to the fossil's ticketing system (I mean a list of tickets that prevent one to complete). I tried adding 'CREATE TABLE blocker(...)' in the Admin-Tickets-Table page and then when creating a new ticket report it says: * **Syntax error: access to blockers.blockerid is prohibited* Is there any way to access a second table from the UI? Do you have any other ideas? Cheers, Jacek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
